I don't think this will work.

I tried adding them to Orbit under the assumption they are available as OSGi bundles from Maven Central but that assumption isn't valid.

[ERROR] Failed to resolve target definition file:/D:/Users/merks/orbit-simrel/git/orbit-simrel/maven-osgi/tp/Maven.target: Artifact io.github.humbleui:skija-linux-x64:0.143.12 is not a bundle and MissingManifestStrategy is set to error for this location

They need to be bundlized which I could do in Orbit probably without much effort...

I wonder if more are needed though?

I also see there are native libraries and those generally should be natively signed for mac and windows:

That adds another complication because there is no other case were I need to both natively and bundlize a jar. I don't really want to create that much work for myself...

Better would be to get the upstream project to publish OSGi bundles.

For my SWT-Skija bridge currently only windows and linux for x86 are supported, so these are sufficient.
About natively signing, i guess we must discuss this.

For RCP libraries we nowadays rely on the automatic JAR to bundle conversion via the target platform. Can this also be used here?

Yes, Orbit relies heavily on bundlizing non-OSGi maven dependencies:

https://github.com/eclipse-orbit/orbit-simrel/blob/main/maven-bnd/tp/MavenBND.target

These are the expectations from a SimRel point of view:

https://github.com/eclipse-simrel/.github/blob/main/wiki/SimRel/Simultaneous_Release_Requirements.md#re-use-and-share-common-third-party-code

Any third-party plug-ins that are common between projects must be consumed via Eclipse Orbit, or if available from Maven Central as an OSGi artifact, maybe be consumed directly from Maven Central, in which case it should be PGP signed and not Jar signed. Third party libraries must not be repackaged as bundles and distributed with a bundle symbolic name that has the potential to conflict with a bundle symbolic name used by another project.

What folks do in a branch that is not feeding into production code is their business but if this is going to be part of production code, as is suggest by the correspond PR on master then, there are processes to follow.

So to use the Skia libraries we must add it to https://github.com/eclipse-orbit/orbit-simrel/blob/main/maven-bnd/tp/MavenBND.target to avoid using the same BSN?

The platform consumes the following things from Orbit for various reasons:

https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/26e312dc6245bf7e196af0fab874b48bf82c0ecd/eclipse.platform.releng.prereqs.sdk/eclipse-sdk-prereqs.target#L5-L39

E.g., not available in the required form in Maven, not available in any proper form in Maven, not available as a bundle in Maven, not natively signed (e.g., Windows and macos shared native libraries, e.g., dll) in Maven.

I really don't know the "long term" plan around these libraries, which architectures are to be support, long term, how this is shipped, and by whom it will be used. I see it was recently changed to not copy the libraries into another bundle and I don't know why that was changed either. Many question...

cc @HeikoKlare

Just an information about Skija.

There are multiple jar files:

• Shared and Types: these should contain only java code.
• The OS dependent parts: these should contain only the native library, which should be the compiled Skia.

So if code signing of native binaries is the problem, Maybe it is possible that SWT builds the Skia binaries themself and only uses the Skija-jars Shared and Types.

In the long term it is the question whether SWT wants to rely on Skija at all or if we build Skia binaries and use FFM-API.

To summarize my understanding: attaching OSGi metadata to all the required JARs is something we can do with the according PDE/Tycho tooling via Orbit. The challenging parts seems to be signing the native libraries together with the creation of OSGi metadata for the jar containing them.

@merks you say:

generally should be signed for mac and windows

Can you shortly explain why you say "should" (and not "must")? I am asking because Skia is supposed to be integrated as an experimental feature to SWT, so that it becomes easy to try out and can be incrementally developed (in best case to fully production-ready state) within the production code. Of course we all hope that we reach production-ready state, still, depending on the results of that testing and development, the feature might be removed again.
That's why I think we should keep the integration as simple as possible for now, In particular, adapting the upstream project to deploy artifacts with OSGi metadat would be the best final solution (like done for JSVG weisJ/jsvg#107), but that's something we should only do if we are sure that we will ship Skia for productive use at some point in time.

People don't necessarily notice if a *.dll isn't signed, but in the end, someone will come and complain that their ultra-awesome security tool is flagging unsigned native libraries. It's worse on macos because one cannot notarize a product that contains a library that contains a native macos library that is not signed.

That's why we have this:

https://github.com/eclipse-orbit/orbit-simrel/blob/89fb8691dc90a414c03278c056babfdc2c85de90/maven-sign/tp/MavenSign.target#L6-L42

When I looked at it later in detail yesterday I saw it said this:

# These instructions are not actually used because this is an OSGi artifact

So it might well be the case that I can simply use a non-OSGi artifact with native libraries here and both bundlize it and sign the nested native libraries. I'd need to experiment but if that's the case the problem is much reduced.

As as an outlook, if all goes relatively smoothly, it's maybe only a day of work or maybe less even. I am generally very careful to look at the OSGi metadata in the actual jars being produced to make sure they are sensible. I've had to manage the budget very carefully, often deferring tasks, because it generally runs out extremely quickly. That's why I wanted to be sure what path we are on here before I invest that effort.

I guess this is sort of blocker and I might consider to prioritize this higher ASAP?

FYI, I did some experimenting today and it looks somewhat promising. I hope I can complete this by the end of the day tomorrow. That being said, I think I need to generate Bundle-NativeCode headers like what I see for com.sun.jna, but I'm not really sure:

I have all the wrapping stuff working but I don't know how exactly the libraries will be loaded from the OSGi runtime bundle. I believe this is doing the loading.

https://github.com/HumbleUI/Skija/blob/master/shared/java/impl/Library.java

This suggests to me that the bundles with the native libraries need to be fragments of the shared host bundle.

So I'd need to synthesize something similar to this which is pretty straight forward:

Fragment-Host: org.eclipse.swt;bundle-version="[3.128.0,4.0.0)"

I'd also need a filter like this in each fragment, which hopefully I can do patterns via a single set of instructions for the different natives:

Eclipse-PlatformFilter: (&(osgi.os=win32)(osgi.arch=x86_64))

I'm really not sure yet how to test that what I generate actually works properly...

@DenisUngemach

Do you have any insights about how this is expected to work as OSGi bundles to speed up my investigation? If not, even just some clue on some simple thing I might try that would only work if the native library is loaded. I'll be out of office soon for the next few hours...

@merks
The skija library is separated in the common part: Shared and Types and the OS dependent parts.

The org.eclipse.swt.skia plugin has the common and the OS parts (win/x86 and linux/x86) as dependency. Then at runtime the shared Layer just loads the library which is supported for the currently running OS and architecture and ignores the other one. The only disadvantage of this approach is the size of the not used OS dependent parts.

So with the experimental state i would recommend to just create one OSGi runtime bundle with the shared, types, (win/x86 and linux/x86) dependencies and make it OS independent. This minimizes work and the org.eclipse.swt.skia plugin can work with that.

@HeikoKlare Your opinion?

That part is all clear. The point though is how exactly will the shared bundle load native libraries from the separate native bundle/fragment in an OSGi runtime? That works differently and is more complex than when these are just jars on a flat classpath.

In the worst case, I’ll make an educated guess and we can refine it later. And it won’t actually matter if you initially use them as plain old jars with a standalone (non-OSGi) launch.

From what I know about the mechanism of adding OSGi metadata to Maven artifacts, it's easiest (if not limited to) making bundles out of the existing Maven arfiacts, i.e., not combining multiple Maven artifacts to a new bundle. To the best of my knowledge, that would require a dedicated Maven build that produces kind of a fat jar and deploys it to some Maven repository.

Ed's proposal of adopting the SWT structure for the Skia dependencies sounds reasonable to me: have a shared host bundle and make fragments out of the Jars with the native libraries with proper platform filters. @merks is it easy to implement that with Orbit and try it out, or should we locally create and test the bundles/fragments that we would expect from the process, so we don't invest too much into the automation now that we don't know for sure yet if that's what will finally work.

BND is very expressive so none of these things are all that challenging. At this point I only need to augment what I already have working to add the two headers for the native fragments. I’ll continue when I arrive at my destination in a few hours.

Is there some simple snippet I might try from an OSGi launch as an early smoke test? That would help quite a bit.

In the org.eclipse.swt.examples plugin you can run: SnippetCanvasCompare

One more info:
Currently in the pom.xml in org.eclipse.swt.skia the jars will be copied to the lib folder. And these jars in the lib, will be added to the classpath.

@DenisUngemach

I created this issue which includes details of what's been added to Orbit:

eclipse-orbit/orbit-simrel#61

The aggregation table shows the new content:

https://download.eclipse.org/tools/orbit/simrel/orbit-aggregation/table.html

Those new bundles and fragments are available in this update site

https://download.eclipse.org/tools/orbit/simrel/orbit-aggregation/nightly/latest

You can change the following

      <!-- skija -->
      <unit id="io.github.humbleui.skija-shared" version="0.143.13.v20260416-1000"/>
      <unit id="io.github.humbleui.skija-linux-arm64" version="0.143.13.v20260417-1000"/>
      <unit id="io.github.humbleui.skija-linux-x64" version="0.143.13.v20260417-1000"/>
      <unit id="io.github.humbleui.skija-macos-arm64" version="0.143.13.v20260417-1000"/>
      <unit id="io.github.humbleui.skija-macos-x64" version="0.143.13.v20260417-1000"/>
      <unit id="io.github.humbleui.skija-windows-x64" version="0.143.13.v20260417-1000"/>
      <unit id="io.github.humbleui.types" version="0.2.0.v20260416-1000"/>

      <!-- This is the "normal" Orbit repository is expected to be updated on milestones and releases based on Orbit deliveries. -->
      <repository location="https://download.eclipse.org/tools/orbit/simrel/orbit-aggregation/nightly/latest"/>
    </location>

Place it here:

These will be available:

Note that a bunch of iplab issues were opened and will need to be reviewed.

Please test and report any problems or concerns here:

eclipse-orbit/orbit-simrel#61

Once we you give the green light on that issue I will build a milestone repository with that content.